home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 6 / QRZ Ham Radio Callsign Database - Volume 6.iso / mac / files / t_gtepms / gteintro.txt < prev    next >
Text File  |  1994-11-27  |  12KB  |  210 lines
  1. Are you presently using an MS-DOS 80286 or 80386 computer as a
  2. platform for your BBS program?  Wouldn't it be nice if you could
  3. unleash all the power in your system's CPU and improve thruput and
  4. gain ports without having to run multiple copies of your BBS program?
  5.  
  6. Imagine a BBS package written expressly for 80286/80386 CPUs with
  7. net/rom emulation, a multi-connect, multi-tasking AX.25 bulletin board
  8. program with a landline port, remote sysop ID security via an
  9. encrypted password, file server support, tcp/ip as an option, and the
  10. ability to query other similar systems for users when a message is
  11. left for someone not known to that particular BBS!  All this with no
  12. need to run multiple copies of the program and making maximum use of
  13. your system's expanded memory or EEMS/LIM 4.0 capability.
  14.  
  15. Impossible, you say?  Nope!  Read on.
  16.  
  17. The package is called the GTE Packet Message Switch (GTEPMS) and was
  18. written by Doug Miller, N2GTE.
  19.  
  20. GTEPMS was beta-tested in the Greater Baltimore (MD) metropolitan
  21. area; a very congested location for packet operations with literally
  22. dozens of BBSs and a fairly organized nodes network.  The beta testers
  23. ranged from computer programmers to computer dummies (me) and out of
  24. that testing, the first general release version 1.2 was distilled.
  25.  
  26. The GTEPMS is designed to operate under Quarterdeck's DESQview and
  27. QEMM memory management programs or under DESQview-386, which combines
  28. the two.  It is DESQview-specific and requires the DESQview/QEMM or
  29. DesqView-386 programs in order to operate properly.  Any IBM 80286 
  30. clone with at least 2 megabytes of EEMS or LIM 4.0 RAM, or an 80386
  31. with at least two megabytes of memory can run this package.  Most of
  32. the beta testers have been using 386SX computers with expanded memory
  33. from 2 thru 5 megabytes.  A majority are using 4 megabytes, which is
  34. recommended by N2GTE.
  35.  
  36. The package consists of the GTEPMS program itself,  G8BPQ networking
  37. software, and tcp/ip programs with modifications made by N2GTE.  The
  38. Quarterdeck programs are not part of the package since they are
  39. commercial programs.  You will need to obtain them from a commercial
  40. source, but the PIF-DVP routines which run the BBS under DesqView are
  41. included in the GTEPMS package.  Also included are sample files which
  42. must be made up in order to run the package.
  43.  
  44. Caution:This is NOT a BBS package for computer novices or beginning
  45. packeteers.  The package assumes a basic knowledge of how DESQview
  46. works, how QEMM works, and how to set up and navigate between Desqview
  47. windows, and a good knowledge of MS-DOS file structure. 
  48.  
  49. HOW IT WORKS:
  50. GTEPMS talks to the outside world via the G8BPQ networking program
  51. written by John Wiseman, G8BPQ.  The two versions of the BPQ code
  52. which are compatible with GTEPMS are versions 3.57 and 3.59.  Later
  53. versions are not, at this time, able to work with GTEPMS, since G8BPQ
  54. radically changed his interface software in versions from 4.0 and
  55. upwards.  The sysop must set up the BPQ program into a net/rom
  56. compatible node which will control all of the ports and connects to
  57. the GTEPMS BBS, and will also interface with any file servers running.
  58. The number of ports and connects are limited only by the number of
  59. TNCs hooked to the BPQ software. BPQ can handle a number of different
  60. TNCs, but they must be TNC-2 type modems and be able to run KISS mode.
  61. An exception is the DRSI PC Packet Adapters which are internal TNCs
  62. and don't need KISS mode to run. Since BPQ can handle up to four DRSI
  63. cards, if you have four empty slots in your computer, you can run up
  64. to eight radio ports without touching the computer's serial ports! For
  65. that matter, if you installed four of the DRSI cards which have two
  66. serial ports instead of radio outputs, you could, theoretically,
  67. connect a dual-port TNC such as the Kantronics KAM or KPC-4 to each
  68. serial port and wind up with 16 radio ports!  That's also the limit
  69. that BPQ can handle.  Wow, a monster BBS system!
  70.  
  71. All BBS routines work within DESQview windows.  Unlike other BBS
  72. programs, only a few are continually open and others operate only when
  73. needed.  As a routine is called, DESQview opens a window for that
  74. purpose, the program is executed, and the window is closed.  This
  75. helps to keep the BBS from slowing down.  Many routines don't run
  76. unless they're needed, so memory is conserved, and time slices are smaller.
  77.  
  78. The exception to this is the BPQ code.  BPQ does not operate under
  79. DESQview; instead, it starts up under a batch file when the system is
  80. first booted up and stays resident.
  81.  
  82. GTEPMS contains three modules which operate the system and are open at
  83. all times in their DesqView windows: LISTER, PORTER, and RESOLVER.
  84.  
  85. LISTER makes lists of things. It oversee's the databases connected to
  86. the BBS such as the user files, mail files, and so on.  It opens the
  87. RESOLVER and PORTER windows when the system is booted-up and cleans up
  88. the mail files.  It also manages the temporary spool files which are
  89. created during mail in/out routines.
  90.  
  91. RESOLVER handles all the mail and bulletin actions in the system.
  92. RESOLVER's main job is to get rid of mail and bulletins. It works with
  93. LISTER to match up hierarchical routing and then queue's outstanding
  94. mail and bulletins for forwarding-out or placing local messages for
  95. users to pick up.  RESOLVER also reads the message headers on
  96. bulletins and mail and automatically places new headers in a file
  97. which is read by LISTER to append hierarchical routing to outbound
  98. mail.
  99.  
  100. PORTER opens and closes the ports used in forwarding and user tasks
  101. and allocates ports to each routine as it is called, and closes those
  102. ports when the task is completed.  Timed routines such as forwarding,
  103. server instructions, also are under PORTER's supervision.
  104.  
  105. A fourth full-time window is the optional IP module.  This is the
  106. tcp/ip window which controls all tcp/ip functions.  This window is not
  107. required to run the BBS.  It can be left out of the system altogether,
  108. but all of the beta testers have run it, and there are some benefits
  109. to having it running.
  110.  
  111. Other windows in the system which are opened only when needed are
  112. those dealing with forwarding actions, user actions, connects, sysop
  113. console usage and such.  The sysop may, if he wants, run a full-time
  114. terminal program which interfaces with the BPQ node.  This enables
  115. monitoring of the traffic running on the channel.  It also enables the
  116. sysop to connect to other stations directly.  The sysop gets into his
  117. BBS via a console window in which he can read mail, send mail, do
  118. sysop things like killing mail, and so on.
  119.  
  120. Whatever tasks are going on, be it multiple user connects, forwarding,
  121. file transfers, or the sysop playing with the console window or
  122. terminal program, the BBS stays up for new connects.
  123.  
  124. GET THIS:
  125. A very unique feature of the GTEPMS is its ability to query other
  126. GTEPMS systems to check for a "home BBS" for a user unknown to the
  127. system when mail arrives or is placed on the board to that person.
  128. This is called a "Remote Service Request".  Basically, the BBS sends
  129. out a message to the other GTEPMS systems saying: "hey, I have a
  130. message here for so-and-so, any of you guys have any information on
  131. him?"  If any other GTEPMS system has that information, it is relayed
  132. to the querying BBS.  This is all done automatically with no sysop
  133. intervention needed!  This goes a long way towards preventing "stuck"
  134. messages, since, if another GTEPMS system has the "home BBS" info it
  135. will be sent and the querying BBS adjusts the forwarding information
  136. automagically and saves the user information permanently.
  137.  
  138. WHO ARE YOU? WHERE ARE YOU?
  139. One of the problems sysops must deal with nowadays with the many BBS
  140. programs which ask a user to enter a "home BBS" the first time he/she
  141. connects is the tendency by many people to enter their TNC mailbox
  142. call instead of a full-service BBS call.  Well, this cannot happen
  143. with a GTEPMS system.  The system has a file containing known
  144. full-service BBSs, the same file used by LISTER and added to by
  145. RESOLVER in maintaining the H-routing database.  If a user enters his
  146. mailbox call, the system will not allow him to do so.  He will be told
  147. that the  callsign is not a recognized BBS and to reenter another
  148. "home BBS" call.  If the user persists, he is asked to send a message
  149. to the sysop to negotiate a listing, in case he really IS a
  150. full-service BBS.
  151.  
  152. SPEED
  153. Many BBS sysops run multiple copies of their BBS program in order to
  154. kludge up a sort of dual-connect system.  The problem is that the
  155. whole thing slows down if all copies of the program are being
  156. accessed.
  157.  
  158. It's not likely that a GTEPMS system will slow down.  There is no need
  159. to run multiple copies of the code.  This system is FAST! A major
  160. reason for the speed is, of course, the computer's clock speed of
  161. 16-25 Mhz as compared to 8-12 Mhz for a PC/XT.  Another reason for the
  162. speed is that  much of the data needed in forwarding is held in a
  163. RAM-disk in the computer's memory.  The information is also held on
  164. disk, but read/write actions go through the RAM disk instead of
  165. through the hard drive.  The recommended size is 128 kilobytes.
  166.  
  167. To gain even greater speed, some sysops have been using disk caching
  168. to store the last X number of read/written files.  This speeds up the
  169. user's lists and reads, since most of the action on the BBS is in
  170. listing and reading mail.  I carry a 128 kilobyte disk cache on my
  171. system created by software from an unrelated program.  Since I have
  172. five megabytes,the cache does not dent the RAM at all.
  173.  
  174. SYSOP PASSWORD SECURITY
  175. A potential problem in any BBS is people pirating the sysop's callsign
  176. and giving themselves sysop privileges, then wreaking havoc on the
  177. system by killing messages and creating false ones with the sysop's
  178. call.  This is prevented in the GTEPMS system by the addition of a
  179. password file.  When the sysop connects to the system over a radio or
  180. phone link, or if someone is pirating the call, the password file will
  181. send a series of random numbers which correspond to characters in the
  182. password.  The reply must exactly match the characters in the password
  183. (and is case-sensitive) or the connect will be aborted.  Console
  184. actions are not affected by this, just those connects coming in via
  185. external links.
  186.  
  187. USER FRIENDLY
  188. GTEPMS is very user friendly (except for that "home BBS" hassle) and
  189. users can pretty much use the BBS intuitively.  The same basic
  190. commands common to most BBSs are used by GTEPMS.  One command which is
  191. unique to GTEPMS is an "over to node" command (O).  Since connects to
  192. the BBS actually go through the BPQ node, a user may elect to connect
  193. to the node after he's finished with his BBS stuff and then use the
  194. node to connect to another station without needing to disconnect from
  195. ]the system first.
  196.  
  197. TCP/IP
  198. Although tcp/ip is not needed to run GTEPMS, it is included in the
  199. distribution disk with many modifications to the KA9Q NET protocol.
  200. Among them is an AX.25 <-> tcp/ip gateway called "MailGaTE" written by
  201. N2GTE which converts SMTP mail to AX.25 and vice versa.  All the
  202. beta testers are running tcp/ip concurrently with GTEPMS.  The two
  203. protocols are unaware of each other but interface with MailGaTe to
  204. port between each other.  
  205.  
  206. So, if you are running a BBS with an 80286 or 80386 machine, you may
  207. want to look into GTEPMS. (freeware? shareware? what mailing addres
  208. and what landline bbs's)
  209.  
  210.